-
Notifications
You must be signed in to change notification settings - Fork 320
2.4.6-headings-and-labels-descriptive-icons #4147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Wording changes to explanation of descriptive icon (different contexts affext interpretation).
minor edit.
minor wording changes
Changing "loupe" to "magnifying glass"
Sounds all very reasonable. Do you want to create a PR on my PR or do you want me to implement those changes? |
@detlevhfischer i provided them as suggestions so that if you agree with them, you can just commit them into your existing PR via GitHub's "commit suggestion" button that follows each of my proposed changes. I would rather you be the one to commit these, as personally am against the idea of someone editing/committing to someone else's PR without explicit permission :) |
I gave you permission, I suggested it :) - but no problem, I think your suggestions are good and I will work them in myself. |
just to reiterate, if it's not obvious: all you need to do is press the "Commit suggestion" for each here in github, no need to manually try to rework your PR |
Co-authored-by: Scott O'Hara <[email protected]>
Co-authored-by: Scott O'Hara <[email protected]>
Co-authored-by: Scott O'Hara <[email protected]>
magnify glass -> magnifying glass (assuming this is the more common term?)
Hey I was just reading about this and I was thinking you might want to add a reference to 1.1.1 Non-text Content to make sure they have an equivalent alternative? |
Discussed on backlog call 2/7 and made some minor changes. Moved to Ready for approval. |
and last name. The first field is labeled <q>First name</q>, the second is labeled <q>Last name</q>.</dd> | ||
<dt>A search field labeled by a magnifying glass icon</dt> | ||
<dd>A search text input is followed by a button containing a magnifying glass icon that activates the search function. | ||
The icon has the string "search" as programmatically determinable label.</dd> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A visible text alternative is also needed. Can we please add an according sentence?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this the whole point of this PR? clarifying that if an icon is "descriptive" enough, it doesn't need text?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is explicity stated: "In some cases, images can serve as descriptive labels without additional text."
Such an image needs a text alternative, but the author does not need to make the alternative visible, just programmatically available (which can be exposed to users in a number of ways, including visibly, through user agents and AT)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickhlauke does this work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This addition would make it seem like all instances of images directly need to have alt text, when in reality the image could have no alt text because the form field’s accname is clear enough. Eg having a search icon with alt=search next to a text field with an accname of search is not what anyone should think they need to do in this situation.
To put it bluntly, this just seems to make this more complicated, and to provide the appropriate nuance, it’d submit more verbiage is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's the text input that needs an accessible name, not the icon/image used as visual label, basically. (which would cross-reference 4.1.2 and, depending how you look at it, 1.1.1)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, sorry I missed that. In that case, its basically only 4.1.2 that is needed not 1.1.1.
Co-authored-by: Alastair Campbell <[email protected]>
<p>Labels and headings do not need to be lengthy. A word, or even a single character, | ||
may suffice if it provides an appropriate cue to finding and navigating content. | ||
</p> | ||
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood. | |
<p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without visible text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood. |
Mentioned this in the call, but for posterity/on the record: I do appreciate that first extra sentence
as this to me still leaves the door open for auditors to fail egregiously bad uses of icons without text. If an auditor makes a subjective judgement call that they believe the icon is not sufficiently understood/clear to users, they can still fail these icon-only labels (though, as this is subjective, there may be differing opinions ... but nothing that we don't already have in other cases). Yes, conceptually, icon-only labels can be problematic for certain users - those who are unfamiliar with a particular icon, or users with cognitive disabilities. But I don't believe the original intent of the SC ever forbade the use of icon-only labels, and insisting that icons should always be accompanied by visibile text (next to the icon, or as a hover/tooltip, or by having a setting where a user can choose between "icon only" / "icon with text label" like some software does) would introduce a novel normative requirement by stealth here, I'd say. |
It's ironic that the sentence "In these cases, authors should ensure that the image and its use as a label (in context) are widely understood" is followed by a button whose purpose I do not know because it has an unfamiliar (to me) icon and no text label or tooltip. |
Yes if you leave that phrase in, we will start to fail icons that we don't find intuitive. I can confirm that as an auditor. I recommend removing the sentence or say that its a best practice. |
We discussed this comment in today's working group TF call and were in unanimous agreement that this situation is intentional and by design; we want it to be the case that auditors may choose to fail icons that are not "widely understood", per the wording this PR is using. |
Closes #4095
A proposed addition to the 2.4.6 Understanding text that states that conventional icons can in some cases serve as descriptive label of form controls. Included is an example of a conventional icon (loupe for search).
See rendered version of the revised 2.4.6 Understanding text (updated 26 Nov 2024)